Do we need a separate ID?

Not strictly, my considerations:

• originally I thought of creating a separate scenario, but then piggy-backed on this one instead. I then stuck with "I need a new subscription ID for it"
• I've thought of cleaning it up and re-creating it (or alternatively, to mutate the existing subscription), but I feel that this might miss cases where the DSS implementation deals with mutations or deletions in a weird way and would have this test pass when a subscription with a new ID might not?
• I don't know what is a more representative use case: creating a subscription on the border of the ISA, or mutating an existing one to touch the ISA instead.

Let me know if I'm over- or rather under-thinking this: the above questions make me think of additional scenario tests cases that would actually be worth doing: I can make myself a note to revisit this as a P3, or earlier if you think it is worth it?

The original intent of having special IDs (via the ID generator) was to make it easy to figure out who left orphaned test objects in the system, and what those test objects were being used for (how they came to be). IDs generated by the IDGenerator can be decoded to determine the owner and resource type (test purpose). I had missed creation of an ad-hoc ID above (which would not fulfill that contract).

I would generally expect just one Subscription to be sufficient to test ISA-Subscription interactions since I would expect that we could usually delete a previous Subscription before testing new Subscription behavior (there would be no need to have two Subscriptions exist simultaneously to test ISA-Subscription interactions). To the extent that's true, I would expect only one Subscription ID. If that assumption isn't true, then of course we should use as many IDs as necessary, though I would be interested to know the thing we're testing that requires two simultaneous Subscriptions. The thing you mention in your second bullet seems like it could qualify.

I don't know what is a more representative use case: creating a subscription on the border of the ISA, or mutating an existing one to touch the ISA instead.

Those do both seem like valid, expected, and separate use cases so it would probably be worth covering both eventually. That level of full coverage on these DSS functions is probably not the highest priority immediately though, so I'd say pick whichever one is easier and put a TODO and/or Issue for the other one (unless doing both now is easy and would be harder later, e.g., due to mentally re-caching).

I'll use a single ID and update the scenario accordingly. As I have all the required pieces available to test the mutation as well as the "newly created" cases I'll implement them at the same time.

On second thought: there is a whole bunch of additional things that we can reasonably do, so I left a TODO to that effect. The possibility of defining and reusing test fragments (as proposed in #380) would also help making the scenario and its documentation more compact if/when we choose to extend it